home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / pine / imap_archive / text0020.txt < prev    next >
Encoding:
Text File  |  1993-07-02  |  4.6 KB  |  107 lines
  1.  
  2.  
  3. On Sun, 27 Sep 1992, Chris Newman wrote:
  4.  
  5. >  Steve Hole <steve@edm.isac.ca> writes:
  6. > >2.  Who is responsible for the development of the message management
  7. > >protocol? Is there a mailing list for this?  What is the status of
  8. > >this effort?
  9.  
  10. > The CMU team (John Myers and myself) have agreed to spearhead the
  11. > design of this protocol.  We have just finished our survey of user
  12. > requirements on campus, and have a final functional requirements
  13. > document for the mail system we will need here (and a draft design
  14. > document).
  15.  
  16. Would it be possible to have a look at this document?   I would be very
  17. interested in comparing the requirements of your organization to the
  18. requirements of the business and government organizations we do work
  19. for.
  20.  
  21. Also, is there a mailing list for discussing these issues - or is the
  22. IMAP list a good enough forum?  Can I suggest that it would be
  23. worthwhile to create or designate a list for such discussions.
  24.  
  25. > I expect us to start design of the protocol in a month or so, and you
  26. > _might_ see an implementation in a year.  The protocol is likely to be
  27. > very similar to IMAP2bis (probably with some of the same commands for
  28. > subscriptions & such).
  29.  
  30. Very good!   This is pretty much as we expected - it should integrate
  31. nicely into the user interfaces.
  32.  
  33. > Delivery acknowledgements are useless (the message will bounce if not
  34. > delivered).
  35.  
  36. I used to think so.  In fact they would be IF all the MTA's in the
  37. world handled bouncing mail correctly.  Unfortunately, many MTA's make
  38. a habit of returning badly addressed mail to the postmaster (actually
  39. MAILER-DAEMON) at the originating site, rather than to the originating
  40. user - especially if the mail originated outside the organizational
  41. domain.    The result of this is that mail often ends up in a postmaster
  42. queue that only infrequently gets checked.
  43.  
  44. Now, I understand that the role of the postmaster should be monitored
  45. and managed correctly, but the reality for us is that it often is not.
  46. In some of networks, we have 50+ departmental workgroups, each with
  47. their own mail servers and assigned domain.  This is a very nice
  48. solution for large hierarchical organizations, but we do find that
  49. administrative functions tend to slip.  For executive class messages
  50. (Very Important Messages VIM :-), even a 15 minute delay on getting the
  51. message back if improperly addressed is enough for the executive to
  52. complain.
  53.  
  54. I agree that the MTA's should deal with this correctly, and I continue
  55. to lobby for policy change within the various development groups (smail,
  56. zmail, sendmail), and do enforce it locally.   The bottom line is, that
  57. delivery acknowledgement would still be beneficial for us, especially
  58. when dealing with external organizations.
  59.  
  60. > Read acknowledgements, and reply are client issues.  If by "automatic
  61. > reply" you mean something like the unix vacation service, we have that
  62. > rated as "NICE" meaning we'll consider it if we get time (I think
  63. > putting support for it in either the management protocol or the user
  64. > directory protocol is reasonable).
  65.  
  66. I agree.  
  67.  
  68. > >4.  Is there an agreement or description of where services like
  69. > >automatic reply should be provided - in the MTA or the MUA?  X.400
  70. > >specifies the message store (which makes sense), but there is no
  71. > >equivalent in the Internet architecture (I think there should be).
  72.  
  73. > Anything that can go in the MUA should, IMHO.  Keeping the MTA &
  74. > mailstore simple and easy to maintain is very important.  Things like
  75. > vacation replies, and automatic filing of incoming mail will probably
  76. > be put at the mailstore end of the MTA.
  77.  
  78. That is pretty much how I thought it would go.   We have already done
  79. some experimentation with smail 3.x drivers to handle automatic reply,
  80. and new mail notification - it already handles forwarding.   
  81.  
  82. > >5.  There was some mention on work being done to implement
  83. > >lightwieght directory access protocols for getting X.500 information
  84. > >quickly.  Could someone point me to these individuals again?  This is
  85. > >very important to us as a mechanism for distributing public keys for
  86. > >PEM.
  87.  
  88. > There's a protocol called CSO/ph which we're going to look into.  If
  89. > it's not good enough, we'll design & write our own.
  90.  
  91. Is CSO/ph an OSI compliant protocol, or some new creation for an
  92. Internet only Directory service?   I know that Andrew has its own
  93. directory service which appears to be quite serviceable - is this what
  94. you are talking about?
  95.  
  96. Cheers.
  97.  
  98. --
  99. Steve Hole                  Director of Research and Communications
  100. ISA Corporation            mail:  steve@edm.isac.ca
  101. Suite 835, 10040 - 104 St.      phone: (403) 420-8081
  102. Edmonton, Alberta, Canada       fax:   (403) 420-8037
  103. T5J 0Z2
  104.  
  105.  
  106.  
  107.